Secure Digital (SD) refers to a non-volatile memory card format developed by the Secure Digital Card Association for use in portable devices. SD technology is used by more than 400 brands across dozens of product categories and more than 8,000 models. A Secure Digital Input/Output (SDIO) card is an extension of the SD specification that covers input/output functions. The extended SDIO specification can be implemented by a card, but also can be implemented in settings other than a card. Specifically, any device or circuitry that, through programming or hardwiring implements the SDIO protocol, may be referred to as an SDIO device. Such a convention is adopted in this disclosure and reference to an “SDIO device” herein includes any card, circuit, chip, system on chip, and the like that implements the SDIO protocol with respect to a host. The expression “SDIO device” may also be used interchangeably with the expression “SDIO module.”
Host devices that support SDIO devices include, for example, personal digital assistants, laptop computers, and/or mobile smart phones. SDIO devices, either in the form of a card, chip, or other circuitry then further support or include various other subsystems acting as functions, such as GPS tuners, modems, FM radio tuners, TV tuners, radio-frequency identification readers, and wireless local area network (WLAN) and Bluetooth interfaces. It should be noted that these examples, as well as those provided in the preceding paragraph, are not intended as comprising an exhaustive list.
The subsystems and/or functions described above are referred to in this disclosure, and in the claims, as “communication subsystems.” This terminology reflects that these subsystems generally relate to communication functions, wherein data is transferred to and from the host device from an external source. At a more fundamental level, the “communications subsystems” are defined as SDIO functions, as is known in the art, according to the SDIO protocol.
During the operation of an SDIO system that includes a host and an SDIO device with a communication subsystem, there are intervals where the communication subsystem (for example a Bluetooth or WLAN interface) can be inactive, and the power state is minimized. The communication subsystem is referred to as being “asleep” or “sleeping” during these intervals of power minimization. In a conventional SDIO communication system, the sleep state of a communication subsystem is actually controlled by the host device.
More specifically, in prior art SDIO communication systems, the power state of the communication subsystem is controlled in two ways. Initially, the host device can instruct an SDIO controller in the SDIO device to refuse to allow the communication subsystem to enter a deep sleep state. More simply put, the host device can specify that the communication subsystem never sleeps or powers down.
A second alternative in the control of the power state of a communication subsystem is that the communication subsystem is allowed to enter the deep sleep state. However in the scenario where the communication subsystem is allowed to sleep, prior to writing any data to the communication subsystem, the host device must signal an inquiry to the SDIO device as to whether the communication subsystem is awake. When the communication subsystem is not awake, an SDIO controller in the SDIO device must first awaken the communication subsystem.
Conventionally, the communication subsystem must then become fully awake, and the SDIO controller must signal to the host that communication can begin. Only when the host device has received a signal from the SDIO controller that the communication subsystem is fully awake does the host device provide a continuous write operation to the SDIO device. The alternative scenario in the conventional SDIO system where a communication subsystem is allowed to sleep is characterized by very significant processing overhead.
In a conventional SDIO system, a host device will typically sends a continuous flow of data blocks to the SDIO device following a write command. A conventional SDIO data transfer 500 of multiple data blocks is illustrated in FIG. 5. The conventional SDIO data transfer 500 is initiated by a write command communicated 501 from the host device 521 to the SDIO device 523, using the SDIO protocol command 53 (“cmd53”). A cmd53 indicates an impending data block transfer. In response to the cmd53, the SDIO device 523 sends 503 a response to the host device 521 that it has received the cmd53.
The host device 521 then sends 505 block #0 to the SDIO device 523. The SDIO device 523 responds by sending 507 a cyclic redundancy check (CRC) which indicates whether there has been any accidental change to the raw data sent in block #0. The host device 521 then sends 509 block #1 to the SDIO device 523. The SDIO device 523 again responds by sending 511 a CRC.
This process of transferring data blocks from the host 521 to the SDIO device 523, followed by a response containing a CRC from the SDIO device 523 to the host 521, continues in the same process described above until the host device 521 sends 513 a final or last data block #N. In this instance, the last data block contains an “end of transaction” (EOT) indicator to communicate to the SDIO device 523 that no further data blocks will be transferred from the host device 523. The SDIO device 523 sends 515 a final CRC status response to confirm receipt of the last data block.
As will be seen further below, the conventional SDIO data transfer illustrated in FIG. 5 is useful in explaining the disclosed embodiments presented herein. In particular, the disclosed embodiments make use of the SDIO protocol by using busy signaling to effectuate an autonomous sleep mode for a communication subsystem in an SDIO device. The claimed embodiments are now summarized.